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0.  ABSTRACT: 

This  paper  describes  the  motivation,  design,  implementation,  and 
some  preliminary  performance  characteristics  of  FLAT,  a  macro  definition 
capability  for  creating  language  enhancors  and  translators.  FLAT  en¬ 
ables  the  user  to  specify  transformations  through  STREX,  a  FORTRAN-! ike 
language,  which  enables  the  specification  of  macros  which  are  then  used 
to  interpretively  alter  incoming  programs.  FLAT  is  specially  adapted  to 
the  processing  of  FORTRAN  programs.  This  paper  shows  how  it  can  be  used 
as  a  deprocedurizer  (or  flattener),  a  dialect-to-dialect  translator,  a 
portability  and  version  control  aid,  and  a  device  for  creating  language 
enhancements  as  sophisticated  as  new  control  structures  and  abstract 
data  types. 


I .  BACKGROUND  AND  MOTIVATION  FOR  PRODUCING  FLAT: 

Over  the  past  several  years  a  significant  number  of  software  analysis 
tools  have  been  produced  by  the  University  of  Colorado  Software  Validation 
Group.  These  tools  have  at  least  initially  been  largely  directed  towards  the 
needs  of  the  Mathematical  Software  community.  Hence  they  have  been  designed  to 
be  portable  over  a  wide  range  of  machines  and  to  analyze  programs  written  in 
FORTRAN.  These  two  considerations  have  led  us  to  code  our  tools  in  FORTRAN.  As 
a  result  we  have  1)  had  good  success  in  readily  rehosting  our  tools  on  a  variety 
of  machines  and  2)  been  able  to  use  our  tools  to  analyze  themselves,  thereby 
increasing  our  confidence  in  them. 

Through  this  considerable  experience  with  FORTRAN,  we  have  come  to  deeply 
understand  some  of  the  significant  shortcomings  of  this  language.  As  tool 
implementors  we  have  chafed  at  the  absence  of  such  features  as  flexible  control 
constructs  and  powerful  data  aggregation  capabilities.  Yet  as  creators  of 
portable  tools  for  producing  mathematical  software  we  felt  a  deep  commitment 
to  FORTRAN,  the  lingua  franca  of  that  community.  In  addition  we  believe  that 
FORTRAN  is,  perhaps  with  the  exception  of  COBOL,  the  most  widely  available, 
most  nearly  standardized  of  all  high  level  languages,  thereby  giving  it  the 
best  prospects  as  a  basis  for  porting  programs.  We  also  found  that  newer 
languages,  such  as  Pascal,  which  offered  superior  control  and  data  aggregation 
facilities  usually  had  drawbacks  of  their  own.  For  example,  Pascal's  block 
structure  is  an  obstacle  to  independent  recompilation  of  subprocedures.  This 
is  a  serious  problem  during  the  development  of  large  tools  such  as  our  DAVE 
system  [0F76,  F076]. 

Pulled  by  these  conflicting  considerations  we  have  chosen  a  course  taken 
by  many  others  before  us  -  namely  to  enhance  the  FORTRAN  language  in  the  ways 
necessary  to  facilitate  our  work.  A  large  number  of  FORTRAN  preprocessors  have 
been  built  to  enhance  FORTRAN  by  the  creation  of  more  powerful  control  constructs. 
We  were  concerned  more  with  the  need  for  flexibly  defining  and  accessing  powerful 
data  aggregates.  Because  the  preprocessors  we  studied  did  not  offer  significant 
capabilities  of  this  sort,  we  constructed  a  system  of  our  own  [0CS73],  This 
capability  enabled  us  to  define  a  rather  limited  class  of  structured  data  types 
and  access  them  from  our  standard  FORTRAN  source  text.  The  Implementation  de¬ 
tails  of  these  data  objects  were  hidden  by  our  data  structuring  capability,  thus 
enabling  us  to  alter  our  data  structures  without  the  need  to  alter  the  source 
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text  which  accessed  them.  This  capability  proved  most  useful,  enabling  us  to 
construct  our  prototype  DAVE  tool  with  a  minimum  amount  of  trauma. 

A  serious  weakness  of  this  capability  is  that  it  conceals  the  imple¬ 
mentation  details  of  the  data  structures  through  the  use  of  layers  of  sub¬ 
routines.  Although  quite  effective  in  concealing  details,  this  technique 
proves  quite  costly  in  execution  time,  necessitating  the  invocation  of  numerous 
subroutines  for  each  data  access. 

Because  of  this  difficulty  we  turned  to  the  consideration  of  a  macro  cap¬ 
ability.  Our  first  goal  was  to  build  a  capability  which  could  deprocedurize 
or  "flatten"  our  code  by  substituting  inline  the  texts  of  subroutines  in  place 
of  the  subroutine  invocations.  We  conceived  of  the  subroutine  text  as  being  a 
sort  of  macro  definition  and  the  subroutine  call  as  being  a  parameterized 
macro  invocation.  We  produced  a  prototype  capability  of  this  sort  and  success¬ 
fully  used  it  to  flatten  the  source  code  for  our  DAVE  system. 

According  to  our  measurements  we  gained  an  improvement  in  execution 
time  of  up  to  50%  by  flattening  only  a  small  number  of  frequently  executed  sub¬ 
program  invocations.  We  then  turned  our  attention  to  building  a  more  general 
macro  processor  to  enable  substantial,  flexible  enhancements  to  FORTRAN.  The 
key  to  doing  this  was  allowing  the  user  to  define  new  source  language  statements 
by  declarations  in  the  macro  language.  Thus,  for  example,  superior  control  flow 
constructs  such  as  CASE,  IF_THEN_ELSE,  and  D0_WHILE  can  readily  be  added  to 
FORTRAN  by  declaring  them  to  be  new  statements  whose  semantics  are  established 
by  means  of  the  text  of  the  macros  which  define  them. 

The  macro  processor  we  created  is  called  FLAT  (Fortran  Language  Augmentation 
Tool).  Perhaps  the  most  important  capability  which  FLAT  offers  is  the  capability 
for  creating  and  accessing  powerful  data  aggregates  while  hiding  their  implemen¬ 
tation  details,  thereby  adding  to  FORTRAN  true  abstract  data  type  capabilities. 

This  is  achieved  by  considering  data  structure  declaration  statements  to  be 
Fortran  language  augmentations  and  data  structure  accessing  constructs  to  be 
new  language  operators.  The  definitions  of  the  declaration  and  accessing  con¬ 
structs  are  made  through  macro  definitions.  As  shall  be  shown  these  definitions 
can  (indeed  must)  share  implementation  details  among  themselves.  These  details 
remain  invisible  to  the  source  code.  Thus  there  is  complete  freedom  to  create 
and  alter  the  implementations  of  data  aggregates  beyond  the  sight  and  control 
of  the  FORTRAN  source  language  coder.  This  Inability  to  see  or  access 
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implementation  details  qualifies  this  data  aggregate  capability  as  an 
abstract  data  type  definition  facility  in  the  classical  sense  [LZ75]. 

FLAT  also  facilitates  the  porting  of  FORTRAN  programs,  an  important 
consideration  for  tool  developers.  Although,  as  already  noted,  FORTRAN  is 
a  widespread,  standardized  language,  it  is  not  entirely  free  of 

portability  problems.  Numerous  dialects  of  the  language  exist,  offering  a 
variety  of  capabilities  for  handling  such  constructs  as  text  strings,  and 
multiple  precision  numeric  quantities.  These  differences  are  particularly 
vexing  to  the  writer  of  analytic  tools  for  mathematical  software,  as  he  must 
be  concerned  with  both  the  manipulation  of  source  text  and  the  correct 
analysis  of  code  dealing  with  all  possible  numeric  data  types.  A  possible, 
but  unsatisfactory,  solution  is  to  create  a  family  of  versions  of  the  tool 
program,  each  intended  for  a  different  host  compiler.  The  difficulty  here 
is  that  each  must  be  maintained  and,  unless  extraordinary  care  is  taken, 
each  assumes  a  character  of  its  own  and  incompatibilities  between  different 
versions  arise.  The  usual  strategy  is  to  write  the  preponderant  majority 
of  the  program  in  a  portable  subset  of  FORTRAN,  such  as  PFORT  [Ryder76]  and 
quarantine  compiler  dependencies  to  a  very  small  body  of  code  which  must  then 
be  recoded  for  every  new  host  compiler.  This  approach  has  been  widely  used 
with  success  but  still  has  its  drawbacks.  The  compiler  dependent  code  is 
usually  written  as  a  set  of  low  level  subroutines.  Hence  it  usually  is 
frequently  invoked,  always  at  the  undesirable  cost  of  subroutine  invocations. 

In  addition  it  still  necessitates  the  creation  and  maintenance  of  a  family 
of  programs  with  the  attendant  multiplication  of  effort  and  potential  for 
drift. 

Through  the  use  of  FLAT,  a  single  master  copy  of  program  text  can  be 
maintained  and  targeted  for  the  different  host  machines  by  translating  it  with 
different  sets  of  macros  designed  to  adapt  the  master  copy  to  the  idiosyncrasies 
of  the  different  host  compilers.  This  approach  has  been  pursued  in  a  limited 
way  [BM77]  with  good  success.  Our  intention  is  to  use  FLAT  to  combine  this 
notion  with  the  capabilities  for  creating  advanced  data  and  control  constructs, 
thereby  enabling  us  to  code  in  a  very  powerful,  highlevel  FORTRAN-like  language, 
yet  still  maintain  a  set  of  completely  consistent  FORTRAN-source  language 
versions  merely  by  performing  macro  expansions  (see  Figure  1). 
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FIGURE  1:  FLAT  as  a  Porting  Mechanism 
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The  remainder  of  this  paper  discusses  the  particular  macro  capabilities 
which  we  have  implemented  in  FLAT.  The  salient  features  of  these  capabilities 
are  flexibility,  power,  and  the  ease  with  which  FLAT  can  be  used  by  FORTRAN 
programmers.  Much  of  the  flexibility  of  FLAT  derives  solely  from  the  fact  that 
it  is  a  macro  capability.  The  user  is  free  to  declare  any  macros  and  define 
them  in  any  way  he  chooses.  Hence  new  statement  types  can  be  added  to  the 
language  and  arbitrary  subroutines  can  be  expanded  as  in-line  code  in  an 
arbitrary  way.  Additional  flexibility  derives  from  the  fact  that  existing 
statements  from  standard  FORTRAN  can  be  redefined  according  to  the  dictates  of 
user  specified  macros.  Thus,  for  example,  the  syntax  and  semantics  of  exist¬ 
ing  FORTRAN  statements  can  be  expanded  to  encompass  new  operators.  Fxamples  of 
this  will  be  shown  in  the  following  section. 

The  power  of  FLAT  derives  in  large  measure  from  the  fact  that  it  provides 
for  more  than  a  straightforward  in  situ  text  insertion  capability.  Macro 
definitions  are  parameterized,  and  source  text  lines  are  considered  to  consist 
of  the  macro  identifier  and  an  argument  string.  Macro  definition  bodies  can 
be  constructed  to  analyze  the  argument  strings  and  to  use  them  as  the  basis 
for  the  construction  of  appropriate  object  text.  Thus,  the  object  text 
produced  may  vary  considerably  from  one  invocation  to  the  next.  In  addition 
a  macro  definition  body  is  capable  of  creating  object  text  and  specifying 
its  insertion  in  any  of  three  places,  corresponding  to  the  site  of  the  macro 
invocation,  a  location  within  the  declaration  block  of  the  invoking  program 
unit,  and  a  location  completely  outside  of  the  invoking  program  unit.  Hence 
a  macro  invocation  can  cause  the  creation  of  entire  utility  routines  and 
FORTRAN  declarations,  as  well  as  executable  code.  This  is  the  primary  vehicle 
for  creating  and  hiding  the  implementation  of  powerful  data  aggregates. 

Finally  it  is  important  to  note  that  care  has  been  taken  to  assure  that 
the  macro  definition  process  is  not  beyond  the  grasp  of  FORTRAN  programmers. 
Macros  are  themselves  defined  by  means  of  code  written  in  STREX,  a  string 
extended  FORTRAN  dialect.  Thus  it  is  expected  that  FORTRAN  programmers  could 
readily  learn  to  produce  their  own  macros. 
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1 1 .  FLAT  TECHNICAL  DESCRIPTION; 

A.  FLAT  Capabilities: 

FLAT  is  a  general  purpose  translation  system  for  FORTRAN  software.  The 
key  theoretical  concepts  behind  FLAT  are  those  of  syntax  directed  translation  and 
tree  transducers  [Baker78,  KP80] .  To  configure  a  specific  translator,  one 
submits  a  context  free  grammar  [AU72]  and  a  set  of  tree  macros  to  the  FLAT  sys¬ 
tem.  The  rewrite  rules  of  the  grammar  determine  the  language  that  the  translator 
will  accept  as  input.  The  tree  macros  are  programs  that  accomplish  the  desired 
translation  by  modifying  the  derivation  tree  [AU72]  of  the  input.  Each  rewrite 
rule  in  the  grammar  is  coupled  with  a  tree  macro.  The  grammar  and  tree  rpacros 
that  configure  a  translator  are  termed  a  translation  specification. 

Once  a  translator  has  been  configured,  it  will  transform  a  segment  of 
text  as  follows.  If  the  submitted  text  is  not  in  the  language  generated  by 
the  translator's  grammar  then  errors  are  issued  where  appropriate  and  the  text 
is  output  unmodified.  Otherwise  a  derivation  tree  for  the  text  is  built  where 
each  vertex  in  the  tree  corresponds  to  a  rewrite  rule  and  hence  a  tree  macro. 
These  tree  macros  are  invoked  when  their  associated  vertices  are  reached  in  a 
traversal  of  the  derivation  tree.  This  activity  results  in  a  modification  of 
the  derivation  tree.  The  string  derived  by  this  modified  tree  is  then  output 
as  the  desired  translation. 

It  is  important  to  note  that  the  idea  of  producing  a  source  code  trans¬ 
formation  system  is  not  new  with  this  effort.  Boyle  has  produced  a  system, 

TAMPR  [BM77] ,  based  on  the  notion  of  supporting  user  specified,  correctness¬ 
preserving  tree  transformations.  Our  own  work  differs  from  TAMPR  most  strik¬ 
ingly  in  that  it  is  specially  adapted  to  the  needs  of  the  FORTRAN  community. 

Thus  the  user  specifies  translations  in  STREX,  a  language  comfortably  close  to 
FORTRAN.  In  addition,  many  primitives  are  supplied  to  facilitate  the  transfor¬ 
mation  of  FORTRAN  programs.  We  conjecture  that  these  primitives  also  give  to 
the  FLAT  system  more  power  than  is  available  through  TAMPR. 

FLAT  has  a  built-in  FORTRAN  grammar.  Thus  FLAT  translators  will  always 
accept  FORTRAN  software  as  input.  This  built-in  grammar  can  be  augmented  at 
the  statement  and  operator  levels  by  the  placement  of  additional  rewrite  rules 
in  a  translation  specification.  Tree  macros  must  accompany  these  additional 
rewrite  rules  but  their  presence  is  optional  for  the  built-in  FORTRAN  rewrite 
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rules.  Whenever  a  tree  macro  is  not  present  in  a  translation  specification  it 
is  assumed  to  be  the  null  program.  Thus  the  translator  configured  from  the 
empty  translation  specification  will  accept  FORTRAN  code  as  input  and  return 
the  same  code  as  output.  This  augmentation  approach  to  translation  specifica¬ 
tions  is  in  keeping  with  FLAT'S  role  as  a  FORTRAN  software  tool.  FLAT  trans¬ 
lators  will  accept  a  specified  superset  of  FORTRAN  as  input  and  perform  a 
translation  based  on  a  selected  subset  of  the  rewrite  rules. 

The  target  or  output  code  of  a  FLAT  translation  is  expected  to  be  FORTRAN, 
although  any  other  language  (e.g.,  assembler,  Pascal)  could  be  output.  To 
facilitate  the  production  of  FORTRAN  as  output,  there  are  a  number  of  special 
primitives  available  to  the  tree  macro  writer  for  this  purpose.  The  efficiency 
of  translated  code  is  dependent  on  the  coding  effort  put  into  the  tree  macros. 
Good  but  not  optimal  results  can  usually  be  obtained  with  little  effort. 

As  already  noted,  the  FLAT  system  can  be  used  to  configure  translators 
for  a  variety  cf  tasks.  In  the  paragraphs  below,  we  describe  in  a  general 
way  how  FLAT  can  be  used  to  create  some  of  these  different  types  of  translators. 

At  the  highest  level  FLAT  can  be  used  as  a  compiler-compiler  [AU72].  In 
order  to  do  so,  one  must  compose  a  translation  specification  encompassing  the 
desired  language  and  transformation.  In  this  case,  the  built-in  FORTRAN  grammar 
is  ignored.  As  an  example  of  this,  FLAT  is  currently  being  used  to  build  a 
compiler  for  a  PASCAL-1  ike  language  which  produces  FORTRAN  as  target  code. 

FLAT  can  be  used  to  extend  the  FORTRAN  language  in  several  ways.  For 
example,  new  data  abstractions  [Morris79,  LZ75]  such  as  a  STRING  or  BIT  VECTOR 
data  type  can  be  added  to  the  language.  This  requires  the  introduction  of 
at  least  one  new  declarative  statement  and  a  number  of  operators  and  execut¬ 
able  statements  for  manipulating  the  data  type.  The  rewrite  rules  for  these 
new  forms  and  tree  macros  which  translate  them  into  standard  FORTRAN  are  all 
that  is  needed  to  accomplish  the  extension.  New  control  structures  such  as 
IF_THEN_ELSE  and  D0_WHILE  can  be  added  by  the  introduction  of  rewirte  rules 
and  tree  macros  for  these  new  statements.  The  tree  programs  necessary  for 
these  forms  are  particularly  simple  and  thus  a  preprocessor  having  the  power 
of  IFTRAN  [IFTRAN75],  for  example,  can  readily  be  configured. 

The  need  for  a  program  flattener  for  a  program  coded  in  FORTRAN  has 
already  been  discussed.  A  FLAT  translator  for  performing  this  flattening 
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can  be  configured  simply  by  specifying  the  appropriate  tree  programs  for  those 
FORTRAN  rewrite  rules  which  correspond  to  the  subroutine  calls  and  function 
references  which  are  to  be  flattened. 

The  utility  of  a  macro  processor  as  a  portability  aid  has  also  been 
discussed.  The  use  of  FLAT  to  accomplish  this  will  be  discussed  in  detail 
shortly. 
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B.  The  Use  of  FLAT: 

The  design  of  FLAT  envisions  two  classes  of  users.  A  small  group  of 
FLAT  experts,  called  macro  writers,  are  responsible  for  configuring  trans¬ 
lators.  Only  macro  writers  need  to  know  how  to  compose  translation  specifi¬ 
cations.  The  second  user  class  is  called  the  using  community  and  consists 
of  those  groups  that  use  any  of  the  translators  provided  by  the  macro  writers. 
The  members  of  the  software  using  community  need  only  know  how  to  program 
code  which  utilizes  any  of  a  translator's  enhancements. 

The  structure  of  FLAT  is  depicted  in  Figure  2.  The  system  consists 
of  a  translation  compiler  and  an  expander.  A  translation  specification  is 
submitted  to  the  translation  compiler  which  results  in  the  creation  of  a 
translation  module.  This  module  consists  of  parsing  tables  and  object  modules 
for  the  tree  macros.  The  expander  when  coupled  with  a  translation  module,  forms 
a  translator  which  takes  a  user's  input  and  transforms  it  accordingly. 

The  translation  specification  and  the  input  have  been  separated  in  the 
FLAT  system  to  accomodate  the  distinction  between  macro  writers  and  the  using 
community.  Furthermore,  a  translation  specification  is  compiled  because  it 
is  expected  to  be  used  repeatedly.  To  interpret  complex  specifications 
for  each  translation  would  be  extremely  inefficient. 

Consider  as  an  example  the  approach  to  porting  illustrated  in  Figure  1. 
This  approach  can  be  implemented  by  using  FLAT  as  follows.  A  group  of  macro 
writers  must  first  compose  a  translation  specification  to  support  a  high-level 
FORTRAN  dialect  as  requested  by  the  using  community.  They  also  write  specifica¬ 
tions  that  configure  porting  translators  for  host  machines  1,  2,  and  3.  Call 
these  specifications  HLF-TS,  Pl-TS,  P2-TS,  and  P3-TS  respectively.  Using  the 
FLAT  translation  compiler,  the  macro  writers  form  the  translation  modules 
HLF-TM,  Pl-TM,  P2-TM,  and  P3-TM  as  follows.* 

Trans1ation_Compiler(S=HLF-TS,M=HLF-TM) 
Translation_Compiler(S=Pi-TS,M=Pi-TM)  for  i  =  1,2,3. 


♦The  functional  notation,  ' i ranslation_Compiler  (S=<file^>,M=<file2>) ' 
denotes  an  application  of  the  translation  compiler,  where  the  translation 
specification  is  <filej>  and  the  resulting  translation  module  is  <file2>. 
Similarly,  in  the  statement  'Expander(I=<filej>,M=<file2>,0=<file3>) 

<filej>  is  the  input,  <file2>  the  translation  module,  and  <fi1e3>  the  result¬ 
ing  output. 
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FIGURE  2:  FLAT  Structure 


Now  suppose  that  a  development  group  in  the  using  community  has  written 
code  for  an  application  system  in  the  Fortran  dialect  they  specified  previously. 
Call  the  code  SC-HLF.  To  run  this  code  on  the  local  machine  requires  invokinq 
the  appropriate  FLAT  translator  and  compiling  the  result  with  the  local 
FORTRAN  compiler.  This  procedure  is  expressed  in  functional  notation  as: 

Expander ( I=SC-HLF,M=HLF-TM,0=SC-F0R) 
Fortran_Compiler(I=SC-F0R,0=SC-BIN) 

Once  the  development  group's  software  is  ready  for  porting  to  machine  i  the 
appropriate  porting  translator  is  used. 

Expander(I=SC-F0R,M=Pi-TM,0=SC-F0Ri) 

The  output,  SC-FORi,  is  then  sent  to  host  machine  i,  where  it  is  subsequently 
compiled  by  that  machine's  FORTRAN  compiler.  Thus  by  writing  the  four  trans¬ 
lation  specifications  above,  the  macro  writers  have  created  an  environment  for 
the  software  using  community  in  which  a  high-level  FORTRAN  can  be  employed  and 
in  which  porting  to  three  additional  machines  is  automatic. 


-12- 


C.  Implementation  of  FLAT: 

In  Figure  3,  the  structure  and  interaction  of  a  translation  module  and 
the  FLAT  expander  are  shown  in  detail.  The  expander  performs  a  translation 
in  three  passes.  In  the  first  pass,  the  front-end  builds  a  derivation  tree 
of  the  input  by  consulting  the  syntax  tables  of  the  translation  module.  This 
derivation  tree  is  output  as  the  first  image.  In  the  second  pass,  the 
evaluator  traverses  the  derivation  tree  calling  the  tree  macros  of  the  trans¬ 
lation  module  when  appropriate.  This  activity  results  in  a  modification  of 
the  derivation  tree  which  constitutes  the  second  image.  In  the  last  pass, 
the  formatter  produces  as  the  final  output  the  string  yielded  by  the  modified 
derivation  tree. 

Up  to  this  point  a  rather  abstract  model  of  FLAT'S  operation  has  been 
given.  FLAT'S  behavior  has  been  described  in  terms  of  context-free  grammars, 
derivation  trees,  and  tree  programs.  A  system  which  tries  to  embrace  the 
full  generality  of  these  concepts,  would  undoubtedly  be  highly  inefficient. 

One  of  the  main  design  aims  of  FLAT  was  to  simplify  these  concepts  in  such  a 
way  that  they  still  provide  a  powerful  translation  capability  for  which  an 
efficient  implementation  is,  nevertheless,  possible.  These  simplifications 
are  described  in  the  paragraphs  below. 

C.l.  Front  End  &  Syntax  Tables: 

A  grave  space  problem  arises  if  one  attempts  to  build  a  derivation 
tree  for  the  entire  input  stream  in  a  straightforward  manner.  The  FLAT 
system  simplifies  matters  by  processing  the  input  text  and  inter-pass  images 
in  sequential  forward  scans,  one  statement  at  a  time.  A  statement  is  defined  in 
the  FORTRAN  sense  of  the  word,  that  is,  as  a  72-character  line,  optionally 
followed  by  up  to  nineteen  66-character  continuation  lines.  There  are  assumed 
to  be  four  types  of  statements  -  header,  specification,  executable,  and  tail  — 
which  must  be  grouped  into  program  units  according  to  the  following  syntax. 

<Input>  «-  <Program_Unit>* 

<Program_Unit>  +  <Header>  ;Specifications>*  <Executable>*  <Tail> 

There  is  also  a  neutral  type  statement  whose  occurrence  in  the  input  is  un¬ 
restricted.  This  organization  supports  the  FORTRAN  notion  of  program  units 
or  modules,  but  other  organizations  are  possible  by  declaring  all  statements 
to  be  neutral  and  placing  the  burden  of  sequence  checking  on  the  tree  programs. 


Translator  in  Detail 
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The  range  of  syntactic  augmentation  allowed  in  a  translation  specification 
is  restricted  to  the  extent  that  a  simple  LL-parsing  [AU72]  scheme  suffices 
in  syntactically  decomposing  the  input.  In  this  scheme,  look-ahead  is  very 
rarely  required  and  usually  involves  the  scanning  of  just  one  or  two  characters. 
The  front-end  builds  a  derivation  tree  for  each  statement  and  outputs  these 
in  sequence.  The  front-end  also  detects  any  syntactic  errors. 

For  each  program  unit,  the  front-end  builds  a  symbol  table  of  the  labels 
and  identifiers  that  occur  in  the  unit.  The  front-end  also  builds  a  global 
symbol  table  of  all  those  identifiers  whose  context  determines  that  their  scope 
is  global  (e.g.,  subroutine  names,  common  block  name,  etc.).  These  tables  are 
used  to  generate  unique  identifiers  and  labels  by  the  tree  macros  in  the 
evaluation  pass.  They  are  also  used  for  associating  attributes  or  descriptors 
with  each  identifier. 

C.2  Evaluator: 

The  FLAT  evaluator  processes  the  derivation  tree  of  each  statement  in 
a  postorder  traversal.  As  each  vertex  is  traversed,  its  associated  tree  macro, 
if  present,  is  invoked.  Conceptually,  tree  macros  can  be  thought  to  trans¬ 
form  the  derivation  tree  directly.  However,  in  the  FLAT  system  the  mechanisms 
for  text  generation  (modification)  are  quite  simple.  A  tree  macro  can  append 
statements,  semantic  error  messages,  and  comments  to  the  text  stream  at 
several  strategic  locations.  In  this  way,  a  tree  macro  can  generate  side 
effects,  document  them,  and  report  semantic  errors.  A  tree  macro  can  also 
modify  the  derivation  tree  containing  the  invoking  vertex,  v,  as  follows. 

The  tree  macro  can  replace  the  string  currently  yielded  by  v  in  the  derivation 
tree  by  any  string  it  chooses  to  produce.  The  tree  macro  receives  as 
arguments,  the  strings  currently  yielded  by  each  son  of  v  in  the  derivation 
tree.  Figure  4  gives  an  example  of  this  text  substitution  process.  In  Figure  4, 
the  operator  subscripts  are  shown  to  indicate  the  order  of  evaluation  followed. 
Also  note  only  the  operators  Fun  and  +  have  defining  tree  macros.  The  other 
operators  are  evaluated  according  to  the  usual  rules  of  FORTRAN. 

Since  the  simple  text  substitution  scheme  employed  in  the  FLAT  system 
deals  only  with  the  strings  yielded  by  derivation  tree  vertices,  a  derivation 
tree  need  never  be  built.  A  simple  text  substitution  algorithm  used  in  many 
of  the  older  macro  processors  [Cole76]  suffices  to  perform  the  desired  trans¬ 
formation  and  only  requires  the  post-order  sequence  of  invoking  vertices.  This 
algorithm  provides  increased  space  and  time  efficiency  especially  when  the 
translation  only  operates  on  a  small  subset  of  the  orammar  rewrite  rules. 


Before  Evaluation: 

Tree  Macros  --  +,  Fun 

The  evaluation  order  is  given 
by  the  operator  subscripts. 


Cons 


After  FunQ : 


<+l0(  <+3(,A' ,  *  B* ' .<Fun8( 'FUN' ,'A' ,'2' )>  )> 


FIGURE  4:  Text  Substitution  Process 
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C.3  Tree  Macros: 

In  FLAT  translation  specifications,  a  tree  macro  is  a  program  unit 
written  in  an  extension  of  FORTRAN  called  STREX  (String  Extended)  FORTRAN. 

A  compiler  for  this  extension  of  FORTRAN  was  produced  by  a  bootstrap  of 
the  FLAT  utility.  The  STREX  language  supports  a  subset  of  FORTRAN  and  has 
the  following  additional  features  - 

1.  A  STRING  data  type. 

2.  A  HEAP  data  type. 

3.  Text  generation  primitives. 

4.  Symbol  table  primitives. 

5.  Global  and  local  macro  communication  primitives. 

STREX  FORTRAN  supports  all  FORTRAN  constructs  except  for  those  involvinq 
I/O  or  Hollerith,  Real,  Double  Precision,  or  Complex  data  types  [ANSI66].  The 
additional  features  are  described  below. 

STREX  supports  the  notion  of  a  string  data  type  in  full  generality 
[Elson73].  Simple  variables,  arrays,  and  functions  can  all  be  declared  to 
be  of  type  string.  The  value  of  a  string  variable  may  vary  arbitrarily  in 
length  at  runtime.  At  the  expression  level  strings  can  be  concatenated, 
substrings  can  be  selected,  the  current  length  can  be  queried,  and  strings 
can  be  tested  for  equality.  String  constants  are  denoted  by  a  sequence  of 
characters  enclosed  in  dollar-signs($).  At  the  statement  level  string  variables 
can  be  assigned  (by  value)  and  the  replacement  of  a  substring  of  a  string 
variable  is  also  possible.  Strings  are  used  in  features  3,  4,  and  5  above. 

The  STREX  heap  data  type  is  a  vector  of  storage  of  arbitrary  length. 

The  elements  of  the  vector  may  be  any  data  type  including  heap.  In  this  way, 
recursive  structures  such  as  lists  and  trees  can  be  readily  implemented.  The 
type  of  a  vector  element  is  latent;  that  is,  it  may  vary  at  runtime.  Whereas 
assignment  is  by  value  for  all  other  data  types,  assignment  to  a  heap  variable 
changes  the  vector  the  variable  refers  to.  Thus  an  assignment  between  two 
heap  variables,  say  HI  =  H2,  causes  HI  to  refer  to  the  vector  referred  to  by 
H2,  and  H2  becomes  undefined.  There  are  primitives  to  determine  the  length 
of  a  variable's  vector  and  whether  a  variable  is  undefined.  There  are  also 
statements  for  creating  and  freeing  heap  vectors.  Heap  variables  are  used  in 
features  4  and  5. 

The  STREX  language  contains  several  statements  which  append  strings  to  the 
output  text  stream  at  any  of  three  locations.  The  string  expressions  used  in 
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these  primitives  are  assumed  to  represent  either  statements,  comments,  labels, 
or  error  messages  depending  on  the  primitive.  The  three  locations  at  which 
a  string  may  be  appended  are: 

a/  immediately  before  the  statement  currently  being  scanned, 
b/  immediately  before  the  first  executable  statement  of  the 
program  unit  currently  being  scanned, 
c/  immediately  before  the  first  statement  of  the  current  program 
unit. 

These  locations  allow  one  to  generate  side-effects,  additional  specification 
statements,  and  additional  program  units,  respectively.  There  are  expression 
level  primitives  for  generating  identifiers  and  labels  which  are  unique  with 
respect  to  either  the  global  symbol  table  or  the  local  symbol  table  of  the 
current  program  unit.  These  primitives  return  the  labels  and  identifiers  as 
strings  and  are  used  in  constructing  branches  and  temporary  variables. 

The  symbol  tables  produced  by  FLAT'S  front  end  are  available  to  the 
macro  writer.  A  heap  variable,  presumably  containing  a  descriptor,  is 
associated  with  each  symbol.  One  can  look  up  a  symbol,  thereby  accessing 
the  symbol's  heap  variable.  This  variable  may  be  accessed  or  modified  according 
to  the  intentions  of  the  macro  writer.  New  symbols  may  be  added  dynamically. 

Tree  macros  can  communicate  to  each  other  in  one  of  two  ways.  Common 
blocks  can  be  included  in  any  tree  macro.  The  extents  of  the  variables  in 
such  a  common  block  are  global  to  the  evaluation  process.  In  this  way, 
global  communication  is  possible  —  any  tree  macro  may  modify  or  access  these 
global  variables.  In  the  event  that  a  son  of  an  invoking  vertex  is  also  an 
invoking  vertex,  the  tree  macro  associated  with  the  son  may  pass  a  heap  vector 
to  the  tree  macro  of  its  father.  This  local  commpni cation  mechanism  is 
accomplished  with  a  pair  of  "pass-catch"  primitives.  This  mechanism  allows 
for  the  bottom-up  propagation  of  synthesized  attributes  (heap  vectors)  [Knuth]. 

C.4  Formatter: 

The  FLAT  formatter  preserves  the  spacing  and  indentation  found  in  the 
input  stream.  This  formatter  has  two  output  ports.  The  primary  output 
contains  the  transformed  text  less  any  comments  or  error  messages.  The  other 
port  is  to  the  printer.  This  output  contains  the  consents  and  error 
messages  and  in  addition  contains  summaries  of  the  tree  macros'  activities. 
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III.  SOME  SIMPLE  FLAT  EXAMPLES; 


Two  FLAT  examples  are  given  in  the  following  paragraphs.  For  each 
example  the  FLAT  translation  specification  is  listed  and  discussed  first. 
The  discussion  is  then  followed  by  a  sample  translation. 

The  first  example  generates  in-line  code  for  the  following  function 
which  computes  the  sum  of  the  elements  of  an  array. 

REAL  FUNCTION  SUM<A,N) 

REAL  A(N) 

SUM  =  0. 

DO  10  I  =  1,N 
10  SUM  =  SUM  +  A(I) 

RETURN 

END 


The 

translation  specification  which  will  perform  this  in-lining  consists  of 

one 

tree  macro  — 

1. 

REFERENCE  B  = 

SUM(A.N) 

2. 

STRING  IL,  I. 

L 

3. 

B  »  .GENR. 

4. 

IL  *  .GENI. 

5. 

I  =  .GENI. 

6. 

L  =  .GENL. 

7. 

EXECUTE 

B  *  $  =  0.$ 

8. 

EXECUTE 

IL  *  $  =  $  *  N 

9. 

EXECUTE 

$D0  $*{_*$  $*I*$=1,$*IL 

10. 

LABEL  L 

11. 

EXECUTE 

$  $*B*$  =  $  *  B  *  $  +  $  *  A  *  $($  *  I  *  $)$ 

12. 

RETURN 

13. 

END 

The  header  of  the  tree  macro  (line  1)  indicates  that  the  macro  is  to 
be  activated  for  every  reference  to  SUM  which  has  two  arguments.  The  vari- 
bles  B,  A,  and  N  in  this  statement  are  implicitly  STRING  variables.  The 
value  of  B  when  the  macro  returns  is  the  string  which  replaces  the  reference. 
The  variables  A  and  N  are  passed  to  the  macro  on  entry  and  their  values  are 
the  strings  representing  the  two  arguments  to  SUM.  Line  2  declares  the 
variables  IL,  I,  and  L  to  be  of  type  STRING. 

In  line  3,  the  value  of  B  Is  assigned  to  an  implicitly  real  identifier 
which  Is  unique  with  respect  to  the  current  program  unit.  Lines  4,  5,  and 
6  have  the  same  effect  except  that  implicit  integer  identifiers  (lines  4  and 
5)  and  labels  (6)  are  generated.  Lines  7  through  11  generate  code  for  the 
function  SUM'S  side-effect  and  place  it  immediately  before  the  current 
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statement.  Each  of  these  lines  consist  of  the  keyword  EXECUTE  or  LABEL 
followed  by  a  string  expression.  The  characters  between  $-signs  are  string 
constants  and  *  denotes  string  concatenation. 

Suppose  one  submitted  the  following  input  to  the  translator  configured 
from  the  above  translation  specification. 

REAL  A(15) »  B(2Q) ,  T(5),  SUM 
READ  (INPUT)  (A( I) ,1=1,15) 

READ  (INPUT)  (B( I) , 1=1,20) 

DO  10  I  =  1,5 

10  IF(I.NE.5)  T( I)  =  SUM(A,3  *  I)  +  SUM(B,20) 

WRITE  (OUTPUT)  (T(I),I=1,4) 

STOP 

END 

The  output  would  be  as  follows 

REAL  A( 15) ,  B ( 20) ,  T(5),  SUM 
READ  (INPUT)  (A(I) ,1=1,15) 

READ  (OUTPUT)  (B( I) , 1=1,15) 

DO  10  I  =  1,5 

IF( .NOT. (I.NE.5) )  GOTO  10 
AOOOOO  =  0. 

100000  =  3*1 

DO  10000  100001  =  1,100000 

10000  AOOOOO  =  AOOOOO  +  A( 100001) 

A 00001  =  0. 

100002  =  20 

DO  10001  100003  =  1,100002 

10001  A 00001  =  A00001  .+  B( 100003) 

T(I)  =  AOOOOO  +  A00001 

10  CONTINUE  . 

WRITE  (OUTPUT)  (T(I) ,1*1,4) 

STOP 

END 


Note  that  the  meaning  of  the  DO  label  10  was  preserved.  The  FLAT  front-end 
automatically  preconditions  the  input  code  so  that  the  meaning  of  labels  is 
preserved.  It  also  splits  the  logical  if  statement  so  that  any  text  placed 
"immediately"  before  the  second  clause  of  the  IF  statement  is  guaranteed  to 
be  executed  just  before  the  execution  of  this  clause.  The  code  produced  is 
not  optimal.  A  slightly  more  sophisticated  tree  macro  would  not  generate 
100002  or  100003  or  the  assignment  to  100002. 

The  second  example  illustrates  the  addition  of  an  IF-THEN-ELSE  control 
structure  to  the  FORTRAN  language.  This  requires  the  addition  of  three 
statements  with  the  syntax  — 
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<statement>  ■*-  'IF*  <expression>  ‘THEN' 

«-  'ELSE' 

-  'ENDIF' 

The  proper  nesting  of  these  statements  is  enforced.  An  ELSE-statement  refers 
to  the  most  recent  IF-statement.  The  translation  specification  consists  of 
four  tree  macros  and  a  global  block. 

1.  GLOBAL  PSHDWN 

2.  HEAP  LABSTK 

3.  END 

4.  STATEMENT/E/  $IF$-.EXP./A-$THEN$ 

5.  INCLUDE  PSHDWN 

6.  HEAP  H 

7.  STRING  LAB 

8.  LAB  =  .GENL. 

9.  EXECUTE  $IF  ( .NOT. ($ *  A  *  $) )  GOTO  $  *  LAB 

10.  NEW  H(2) 

11.  H( 1 , . HEP. )  =  LABSTK 

12.  H(2,.STR. )  =  LAB 

13.  LABSTK  =  H 

14.  RETURN 

15.  END 

16.  STATEMENT/ E/  $ELSE$ 

17.  INCLUDE  PSHDWN 

18.  STRING  LAB 

19.  IF  (.UNDEF. LABSTK)  GOTO  10 

20.  LAB  =  .GENL. 

21.  EXECUTE  $G0T0$  *  LAB 

22.  LABEL  LABSTK ( 2, .STR. ) 

23.  LABSTK(2,.STR.)  =  LAB 

24.  RETURN 

25.  10  ERROR  $IMPR0PER  NESTINGS 

26.  RETURN 

27.  END 

28.  STATEMENT/E/  $END$-$IF$ 

29.  INCLUDE  PSHDWN 

30.  IF  (.UNDEF. LABSTK)  GOTO  10 

31.  LABEL  LABSTK (2,. STR.) 

32.  LABSTK  =  LABSTK ( 1 ,. HEP. ) 

33.  RETURN 

34.  10  ERROR  $IMPR0PER  NESTINGS 

35.  RETURN 

36.  END 

37.  END  OF  UNIT 

38.  INCLUDE  PSHDWN 

39.  IF  (.UNDEF. LABSTK)  RETURN 

40.  ERROR  SIMPROPER  NESTINGS 

41.  FREE  LABSTK 

42.  RETURN 

43.  END 
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In  lines  1  through  3  a  global  block  called  PSHDWN  is  declared  to  con¬ 
sist  of  the  single  HEAP  variable  LABSTK.  LABSTK  will  be  used  to  implement 
a  pushdown  stack  of  the  labels  being  used  in  the  transformation.  The 
INCLUDE  statements  (lines  5,  17,  29,  and  38)  in  each  of  the  tree  macros 
indicate  that  the  variables  in  the  PSHDWN  global  block  are  to  be  used  by 
these  macros. 

The  first  tree  macro  (lines  4  to  15)  corresponds  to  the  IF-THEN  state¬ 
ment.  In  lines  8  and  9  the  appropriate  conditional  branch  is  generated.  The 
label  used  in  this  branch  is  pushed  onto  the  LABSTK  push  down  stack  in  lines 
10  through  13. 

The  ELSE  tree  macro  (lines  16  to  27)  checks  the  nesting  of  statements 
(line  19)  and  produces  an  error  message  if  appropriate  (line  25).  If  the 
nesting  is  correct  then  a  branch  is  generated  to  tie  off  the  IF-THEN  clause 
and  this  clause's  target  label  is  appended  to  output  (lines  20-22).  The 
ELSE  label  replaces  the  IF-THEN  label  in  the  top  element  of  the  push-down 
stack  (line  23). 

The  END- IF  tree  macro  (lines  28-36)  also  checks  the  nesting  of  statements 
(line  30).  If  there  are  no  errors  then  the  current  target  label  is  appended 
to  the  output  and  the  push-down  stack  is  popped  (lines  31  and  32). 

The  last  tree  macro  (lines  37  to  43)  is  a  special  macro  which  is 
activated  whenever  the  end  of  a  program  unit  is  reached.  This  macro  checks 
the  nesting  of  statements  and  frees  the  push-down  stack. 

Suppose  one  submitted  the  following  input  to  the  translator  configured 
from  this  translation  specification. 


IF  I.NE.0  THEN 
IF  J.NE.0  THEN 
A  =  A  +  I  +  J 

ELSE 

A  =  A  +  I 

END  IF 
ELSE 

IF  J.NE.0  THEN 
A  =  A  +  J 

END  IF 
ENDIF 


The  output  would  be  as  follows  -- 


IF  (.NOT. ( I . NE . 0 ) )  GOTO  10000 
IF( .NOT. ( J.NE.0) )  GOTO  10001 
A  =  A  +  I  +  J 
GOTO  10002 

10001  A  =  A  +  I 

10002  GOTO  10003 

10000  IF  ( .NOT. (J.NE.0) )  GOTO  10004 
A  =  A  +  J 

10004  CONTINUE 

10003  . 


Once  again  the  semantics  of  the  transformation  is  correct  but  not 
optimal.  The  use  of  .NOT.  could  be  folded  in  the  three  IF  statements.  The 
statement  "GOTO  10003"  is  spurious.  A  more  sophisticated  translation 
specification  could  avoid  these  failings. 

This  concludes  the  technical  description  of  FLAT.  Appendix  A  contains 
the  grammar  for  STREX  FORTRAN.  Appendix  B  illustrates  an  ambitious  trans¬ 
lator  for  a  bit  vector  data  type. 


L. 


-23- 


IV.  EXPERIENCES  AND  FUTURE  WORK 

FLAT  is  written  in  a  portable  subset  of  FORTRAN  66,  in  which  machine 
dependencies  have  been  quarantined  to  a  small  set  of  subprograms.  We  intend 
to  use  FLAT  to  write  macro  sets  which  will  enable  us  to  transform  a  standard 
FLAT  source  text  so  that  FLAT  can  be  ported  to  a  modest  set  of  host  compilers. 
At  present  FLAT  consists  of  12,000  lines  of  source  text. 

FLAT  is  at  this  writing  (June  1980)  just  becoming  operational,  hence 
empirical  data  about  its  performance  is  currently  sketchy  and  unreliable.  As 
indicated  earlier,  we  are  producing  the  STREX  compiler  module  of  FLAT  by  a 
bootstrapping  operation  utilizing  a  prototype  version  of  FLAT.  Early  debugging 
runs  indicate  that  the  STREX  compiler  will  operate  at  a  speed  of  at  least  16 
source  lines  per  second.  The  speed  of  FLAT  in  translating  enhanced  Fortran 
dialects  will,  of  course,  vary  with  the  complexity  of  the  macros  defining 
the  particular  Fortran  enhancement.  Nevertheless,  early  indications  are 
that  FLAT  should  be  expected  to  emit  translations  at  a  rate  of  at  least  30 
object  lines/second  for  a  modestly  enhanced  Fortran  dialect. 

We  are  currently  in  the  late  stages  of  using  FLAT  to  define  a  trans¬ 
lator  capable  of  accepting  as  input  esentially  a  large  subset  of  PASCAL  and 
producing  as  output  essentially  Fortran  66.  The  completion  of  this  translator 
will  mark  the  beginning  of  our  efforts  to  use  FLAT  as  a  production  tool.  We 
expect  to  use  this  translator,  along  with  the  sets  of  Fortran-dialect-specific 
macro  adapters  mentioned  earlier,  to  target  a  large  PASCAL  program  simultane¬ 
ously  for  a  modest  range  of  host  Fortran  compilers.  This  attempt  will  do  much 
to  help  us  evaluate  the  practicality  of  this  macro  approach  as  a  portability 
and  version  control  aid. 


) 
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APPENDIX  A:  THE  SYNTAX  OF  STREX  FORTRAN 

An  extended  version  of  Backus  Naur  Form  grammar  rules  will  be  used  to 
describe  the  syntax  of  a  STREX  translation  specification.  Non-terminals 
will  consist  of  the  token 's  name  surrounded  by  angle  brackets,  e.g. 

<Program_Unit> 

Terminal  strings  will  be  enclosed  in  single  quotes,  e.g. 

'STRING' 

A  plus  sign  will  be  used  to  compress  several  rules  having  the  same  left-hand 
sides,  e.g. 


<A>  *■  <B>  +  <C>  =  <A>  «-  <B> 

<A>  <C> 

A  superscript  star  will  denote  zero  or  more  repitions,  e.q. 

\ 

<A>  <B>*  s  <A>  *■  "  +  <A>*B> 

Curly  braces  will  be  used  for  bracketing  purposes,  e.g. 

<A>  {<B>  <C>}*  <D>  =  <A>  *■  <D>  +  <B><C><A> 

An  exclamation  mark  will  denote  optional  occurrence,  e.g. 

<A>  +■  <C>!  =  <A>  +■  1  '+  <C> 


In  STREX  FORTRAN  there  are  four  different  kinds  of  data  types  or  modes  - 

STRING  INTEGER 

HEAP  LOGICAL 

The  semantic  notion  of  data  type  is  included  in  this  grammar  spec¬ 
ification  by  considering  the  above  modes  to  be  attributes  of  the  various 
non-terminals.  For  example,  <IdeSTRING>  asserts  that  the  identifier 
in  question  Is  of  mode  STRING.  These  attributes  are  synthesized  in  all 
executable  statements,  and  inherited  in  all  others. 
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I.  PROGRAM  UNIT  LEVEL: 

<Translation_Specif1cation>  «-  <Program_Unit>* 

<Program  Unit>  <Header>  {  <Type  Declaration  +  <Includes>  } 

★ 

<Executable>  <End> 

★ 

+  <Global_Header>  <Type_Declarations>  <End> 

<Header>  «-  <Macro_Header>  +  <Subroutine_Header>  +  <Function_Header> 

<Executable>  «-  <Assignment> 

+  <Heap_Allocation> 

+  <Text_Generation> 

+  <Return> 

+  <Continue> 

+  <IF_Statements> 

+  <DO_Statement> 

+  <GO_TO_Statements> 

+  <CALL_Statement> 

+  <Catch_Statement> 

+  <Symbol_Statements> 


II.  STATEMENT  LEVEL: 

A.  Headers: 

<Global_Header>  'GLOBAL'  <Global_Id> 

<Subroutine_Header>  «-  'SUBROUTINE'  <Sub_Id> 

{  '('  <Id>  {  <Id>  }*  ')'  }I 

<Funct1on_Header>  <T_Type>  'FUNCTION'  <S1mple_IdeT_Type> 

'('  <Id>  {  <Id>  }*  ')' 
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<Macro_Header>  <STRING_Temp1ate>  +  <IDENTIFIER_Template> 

+  <OPERATOR_Template>  +  <REFERENCE_Template> 

+  <INVOCATION_Template>  +  <SPECIAL_Template> 

+  <STATEMENT_T  emp 1  a te> 

<STRING_Template>  'STRING'  <Return_Arg_Id>  '  =  '  '$'  <Arg_Id>  '$' 

<IDENTIFIER_Template>  'IDENTIFIER'  <Return_Arg_Id>  '  =  ' 

{  <Id>  +  <Wild_Id>  } 

<OPERATOR_Templ ate>  '  ZOP '  <Return_Arg_Id>  '  =  '  {  <Id>  +  <Wild_Id>  } 

+  'UOP '  <Return_Arg_Id>  '=' 

{  •+'+»-•+•.'  {  <id>  +  <Wild_Id>  }  '.'  } 

<Arg_Id> 

+  'BOP'  <Return_Arg_Id>  '='  <Arg_Id> 

{  <Wild_Id>  '.' 

+  {  •+'  +  +  •*'  +  ■ / •  +  •**• 

+  '.'  <Id>  }  '('  <Int>  ')'  } 

<Arg_Id> 

<REFERENCE_Templ ate>  <-  'REFERENCE'  <Return_Arg_Id>  '=' 

{  <Wild_Id>  '('  <H_Wild_Id>  ')' 

+  <Id>  '('  {  <H_Wild_Id>  +  <Arg_Id>  {’,'  <Arg_Id>}*}  ')'} 

<INVOCATION_Template>  ^  'INVOCATION' 

{  <W11d_Id>  '('  <H_Wild_Id>  ')' 

+  <Id>  '('  {  <H_Wild_Id>  +  <Arg_Id>  <Arg_Id>}*}  ')'} 

<SPECIAL_Template>  -h  {  'START'  +  'END'  }  'OF'  'TEXT' 

+  'START'  'OF'  'UNIT'  '('  <Arg_Id>  ')' 

+  'EXIT' 

+  'ENTRY' 

+  'TERMINATION' 
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<STATEMENT  Template>  •*-  'STATEMENT'  {  */'  {  'H*  +  'S'  +  'E'  +  'T'  +  'N'  }  •/'  }! 

★ 

<Arg_Del>  {  '-'  <Arg_De1>  > 

<ArgJDel>  <Delimiter> 

+  <Phrase>  '/'  <Arg_Id> 

+  <H_Phrase>  '/'  <H_Arg_Id> 

<Delimiter>  «-  '$'  <Char>  '$' 

<Phrase>  '.ID.'  +  '.GID.'  +  '.REF.'  +  \STR.'  +  '.INT.'  +  '.EXP.' 
<H_Phrase>  +  'LIST'  '('  <DeI>  {  '-'  <Del>  }*  ')' 

<Del>  <Delimiter>  +  <Phrase>  +  <H_Phrase> 

<Retum_Arg_Id>  <Simple_Idr.STRING> 

<Arg_Id>  +-  <Simple_IdeSTRING> 

<H_Arg_Id>  <Simple_IdeHEAP> 

<Wi Id Id>  4-  •*'  <Simple_IdeSTRING>  '*' 

<H_Wild_Id>  <S imp! e_Id eHEAP>  '*' 


B.  Specifications: 

* 

<Type_Declarations>  +•  <T_Type>  <RefeT_Type>  {  ','  <RefeT_Type>  } 

+  <T_Type>  'REFERENCE'  <Fun_IdeF_Type>  {  <Fun_IdeF_Type>  } 


<T_Type>  <-  'HEAP'  +  'STRING'  +  'INTEGER'  +  'LOGICAL' 


<Includes>  *■  'INCLUDE'  <Globali_Id> 
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C.  Executable  Statements: 

<Assignment>  <VRefeSTRING  >  '  =  '  <ExpeSTRING> 

+  <VRefeHEAP>  '  =  '  <ExpeHEAP> 

+  <VRefeINTEGER>  <ExpeINTEGER> 

+  <VRefeLOGICAL>  '='  <ExpeLOGICAL> 

+  <VRefeSTRING>  '('  <ExpeINTEGER>  {  <ExpeINTEGER>  }!  ')' 

<ExpeSTRING> 

<Heap_A11ocation>  «-  'FREE'  <VRefeHEAP> 

+  'NEW'  <VRefeHEAP>  '('  <ExpeINTEGER>  ’)' 

<Text_Generation>  ♦  {  'EXECUTE'  +  'LABEL'  +  'COMMENT*  +  'ERROR'  + 

'DECLARE'  +  'CREATE*  }  <ExpeSTRING> 

<Return>  «-  'RETURN'  +  'PASS'  <VRefeHEAP> 

<Continue>  'CONTINUE' 

<IF_Statements>  ♦  'IF'  '('  <ExpeLOGICAL>  ')' 

{  <Executable>+  +  <Label>  ','  <Label>  ','  <Label>  } 

+  =  All  except  DOJStatement 

<DO_Statement>  «-  'DO'  <Label>  <Simple_IdeINTEGER>  '  =  ' 

<ExpeINTEGER>  ','  <ExpeINTEGER>  {  <ExpeINTEGER>  }! 

<GO_TO_Statements>  *■  'GO'  'TO'  {  <LabeI> 

+  '('  <Labe1>  {','  <Labe1>}*  ')'  ','  <IdeINTEGER>  } 

<CALL_Statement>  «-  'CALL'  <Sut>_Id>  {  '('  <Exp>  {  <Exp>  }*  ')'  }!  , 

<Catch_Statement>  «-  'CATCH'  (<VRefiSTRING>  +  <FRefeHEAP>  }  'IN'  <RefeHEAP> 
<Symbo1_Statements>  «-  'LOOKUP'  {  '('  'GLOBAL'  ')'  }!  <ExpeSTRING>  'IN'  <RefcHEAP> 

D.  End: 


<End>  «-  'END' 
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III.  EXPRESSION  LEVEL: 


<ExpeBOP(T^  ,T^)>  +- 

<ExpeT^>  <Bop> 

<ExpeT2> 

Operator 

Precedence 

Type  Rules 

** 

100 

**(  INTEGER, INTEGER)  =  INTEGER 

★ 

200 

*(STRING, STRING)  =  STRING 
♦(INTEGER, INTEGER)  =  INTEGER 

/ 

200 

/(INTEGER, INTEGER)  =  INTEGER 

300 

+( INTEGER, INTEGER)  = 

-(INTEGER, INTEGER)  =  INTEGER 

.NE...EQ. 

400 

.NE. (STRING, STRING)  = 

.EQ. (STRING, STRING)  = 

.NE.t INTEGER, INTEGER)  = 

.EQ. (INTEGER, INTEGER)  =  LOGICAL 

. GT . , . GE . , 
.LT...LE. 

400 

.GT. (INTEGER, INTEGER)  = 

.GE.( INTEGER, INTEGER)  = 

.LT.( INTEGER, INTEGER)  = 

.LE.( INTEGER, INTEGER)  =  LOGICAL 

.AND. ,.OR. 

500 

.AND. (LOGICAL, LOGICAL)  = 

.OR. (LOGICAL, LOGICAL)  =  LOGICAL 

<ExpeUOP(T)>  «-  <Uop>  <ExpeT> 


Operator 
.CONVER. 
. INTERP. 
.UNOEF. 


Type  Rules 

.CONVER. (INTEGER)  =  STRING 
.INTERP. (STRING)  =  INTEGER 
.UNOEF. (HEAP+STRING)  =  LOGICAL 
+( INTEGER)  =  -(INTEGER)  =  INTEGER 
•LENGTH. (HEAP+STRING)  =  INTEGER 


.LENGTH. 
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<ExpeT>  «►  '  ( '  <ExpeT>  ' ) ' 

<ExpeSTRING>  ■«-  ' .EMPSTR.'  +  '$'  <Char>+  '$' 

<ExpeINTEGER>  ■*-  <Int> 

<ExpeT>  <■  <VRefeT>  +  <FRef*HEAP> 

<ExpeSTRING>  4-  <ExpeSTRING>  '('  <ExpeINTEGER>  {  <ExpeINTEGER>  }!  ')' 


IV.  REFERENCE  LEVEL: 

<RefeT_Type>  «-  <Simple_IdeT_Type> 

+  <Array  IdeT_Type>  '('  <ExpeINTEGER>  {  <ExpeINTEGER>  }  ')' 

<VRefeT__Type>  <RefeT_Type> 

+  <RefeHEAP>  ' ( ’  <ExpeINTEGER>  ' , 1  <CoerceTType>  ' ) ' 

<CoerceHEAP>  4-  '.HEP.' 

<CoerceSTRING>  <-  * .STR. ’ 

<CoerceINTEGER>  4-  MNT. ' 

<CoerceLOGICAL>  4-  '.LOG. ' 

^  <FRefeT_Type>  *■  <Fun_IdeT_Type>  '('  <Exp>  {  <Exp>  }  ')'  + 

*  =  All  FORTRAN  Intrinsic  functions  on  INTEGERS  and  LOGICALs 
are  supported. 

V.  IDENTIFIER  LEVEL: 

<Simple_Id>  *-  <Id> 

<Array_Id>  •*-  <Id> 

<Fun_Id>  <Id> 

<Sub_Id>  *■  <Id> 


<Global  Id>  ■*-  <Id> 
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APPENDIX  B:  A  FLAT  TRANSLATOR  FOR  A  BIT-VECTOR  DATA  TYPE 

Many  algorithms  employ  the  notion  of  a  set  whose  underlying  implementa¬ 
tion  is  assumed  to  utilize  bit  vectors.  This  provides  the  motivation  for  ex¬ 
tending  the  FORTRAN  language  to  incorporate  a  BIT  VECTOR  data  type  vie.  a 
FLAT  translator.  Such  an  extension  is  described  in  this  appendix. 

We  begin  by  informally  describing  the  syntax  and  semantics  of  the 
augmentation.  Simple  variables  and  arrays  may  be  declared  to  be  of  type 
BIT  VECTOR.  For  example,  the  statement  'BIT  VECT0R(180)  A,B(10)‘  declares 
A  to  be  a  bit  vector  of  180  bits,  and  B  to  be  a  10  element  array  whose  elements 
are  bit  vectors  of  180  bits.  Bit  vector  variables  may  be  formal  parameters 
but  not  function  names.  It  was  also  thought  to  be  convenient  to  allow  one 
to  declare  integer  constants.  For  instance, 

CONSTANT  NPROC  =  100 
CONSTANT  NVAR  =  1000 

declares  NVAR  to  be  the  constant  1000  and  NPROC  to  be  the  constant  100. 

These  statements  can  occur  anywhere  within  the  input  and  apply  in  all  sub¬ 
sequent  code.  For  example, 

BIT  VECTOR(NVAR)  LOCAL(NPROC) 

declares  LOCAL  to  be  a  100  element  array  of  1000  bit  bit  vectors. 

Bit  vector  arithmetic  is  performed  with  the  aid  of  a  number  of  binary, 
unary,  and  nullary  operators  with  which  one  can  build  expressions.  These 
bit  vector  operations  are  sketched  in  the  table  below. 


_ Op 

Precedence 

Type  of  Result 

Meaninq 

A.NE.B 

400 (lowest) 

LOGICAL 

A  *  B 

a.eq.b 

400 

LOGICAL 

A  =  B 

A.  UNION. B 

300 

BIT  VECTOR 

C 

00 

A. INTER. B 

200 

BIT  VECTOR 

A  n  B 

A.DIFF.B 

lOO(highest) 

BIT  VECTOR 

A  -  B 

.COMP. A 

- 

BIT  VECTOR 

a,  A 

.EMPTY. 

- 

BIT  VECTOR 

0 

.UNIV. 

- 

BIT  VECTOR 

*  0 

For  all  binary  operators,  the  arguments  must  be  bit  vectors  of  the  same  length. 
Additional  operators  can  be  supported  as  needed  by  adding  to  the  translation 
specification  which  supports  this  extension  (see  Figure  B2).  A  specific  bit 
of  a  bit  vector  may  be  tested  by  referencing  the  bit's  position.  For  example, 
the  expression  ' (A. INTER. B(l) ) (1*3) '  returns  a  logical  value  which  is  true  if 
and  only  if  the  bits  of  both  A  and  B(l)  are  set.  Bit  vector  expressions 

may  be  actual  arguments  to  a  procedure  invocation. 

Assignment  is  extended  to  include  the  BIT  VECTOR  data  type.  For  example, 
the  statement  ' B(3)  =  .COMP. A'  assigns  the  bit  vector  value  of  the  expression 
.COMP. A  to  the  variable  B(3).  In  addition,  individual  bits  can  also  be 
assigned.  For  example,  1 B (3 ) ( 2)  =  .TRUE.'  sets  the  second  bit  of  B(3)  and 
'B (3) (2)  =  A(2)'  assigns  the  second  bit  of  B(3)  to  the  value  of  the  second 
bit  of  A. 

The  translation  specification  which  supports  this  extension  is  listed  in 
Figure  B2.  The  code  is  quite  lengthy  (approximately  400  lines)  and  thus  will 
not  be  discussed  in  detail.  Instead,  the  nature  of  the  transformation  this 
translation  specification  performs  will  be  discussed  using  the  sample  trans¬ 
lation  in  Figure  B1  as  an  example. 

All  occurrences  of  a  constant  identifier  are  replaced  with  the  constant 
assigned  to  the  identifier.  For  example,  in  Figure  Bl,  'COMMON  /LIST/  LLST, 
LARR(NVAR) '  becomes  'COMMON  /LIST/  LLST, LARR( 1000) ' .  All  bit  vector  variables 
are  turned  into  integer  arrays  by  the  addition  of  an  extra  dimension.  The 
size  of  this  dimension  is  the  number  of  words  required  by  a  bit  vector.  The 
specification  in  Figure  B2  is  for  a  CDC  6600  which  has  60  bit  words.  Thus 
the  declaration,  'BIT  VECTOR(NVAR)  TV'  becomes  'INTEGER  TV(17) '  where  17 
equals  (NVAR-D/60+1. 

Any  reference  to  a  bit  vector  variable  within  the  executable  part  of 
a  program  unit,  is  transformed  into  an  augmented  array  reference  where  the 
extra  dimension  is  a  unique  free  variable.  For  example,  a  reference  to  'TP' 
becomes  ' TP( 100000) '  and  a  reference  to  'AT(SN)'  becomes  ' AT ( 1 00000 , SN ) ' . 

The  free  variable,  100000,  is  used  as  required  by  the  context  of  the  reference. 
For  example,  the  assignment  'AT(SN)  =  TP'  is  transformed  into  the  two  lines 
of  code  — 

DO  10004  100000  =1,2 
10004  AT( 180000, SN)  =  TP(I00000) 
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By  constructing  a  do  loop  in  which  the  free  variable  is  the  index,  the  assign¬ 
ment  takes  place  word  by  word.  As  another  example  of  the  context  sensitive 
usage  of  the  free  variable,  consider  the  code  generated  for  the  bit  selection 
in  the  statement  'IF  ( .NOT.ATB(SNP){R))  GO  TO  60'  - 

100000  =  (R-D/60+1 
100001  =  R-( 100000-1 )*60 

100005  =  (ATB(I00000,SNP). AND. 100002(100001)). NE.0 
IF( .NOT. 100005)  GO  TO  60 

The  free  variable  pair  ( 100000,100001 )  determine  the  word  and  index  within 
the  word  of  the  selected  bit  R.  100005  is  a  generated  logical  variable  in 
which  the  result  of  the  bit  selection  is  stored.  100002(100001)  is  a  constant 
word  whose  100001th  bit  is  set  in  the  block  data  unit  initializing  100002. 

The  free  variable  is  not  bound,  however,  when  forming  bit  vector  ex¬ 
pressions.  For  example,  the  expression  'LOCAL(P). DIFF. FORMAL(P). INTER. OPT(P)' 
is  transformed  into  'LOCAL(IOOOOO.P) .AND. . NOT. FORMAL (I 00000, P). AND. OPT (I 00000, P) ! . 
The  free  variable  is  not  bound  until  a  context  like  the  ones  above  is  reached. 

In  Figure  Bl,  the  expression  is  passed  by  value  to  the  subroutine  LIST  in  the 
statement  'CALL  LIST(LOCAL(P) .DIFF. FORMAL (P) . INTER. OPT(P) ,NVAR) ' .  The  code 
generated  for  this  statement  is  - 

DO  10003  100000  =1,17 

10003  100003(100000)  =  L0CAL( 100000, P) .AND. NOT. FORMAL ( 100000, P. AND. 0PT( 100000, P) 

CALL  LIST( 100003, 1000) 

A  unique  bit  vector  variable  100003  is  generated  and  the  value  of  the  expression 
is  assigned  to  it.  100003  is  then  passed  to  LIST  as  an  actual  argument. 

Some  features  of  the  translator  are  not  illustrated  in  Figure  Bl.  The 
constants  .EMPTY,  and  .UNIV.  are  folded  whenever  possible.  That  is,  an  ex¬ 
pression  like  (A. INTER. .EMPTY.) .DIFF. B  is  simplified  to  '.COMP.B'.  Semantic 
errors  such  as  type  incompatibilities  are  detected  and  reported.  For  example, 
the  expression  'TP(SNP) (P) .AND. AT'  is  transformed  into  '**ERR0R**.AND.**ERR0R**' 
as  TP(SNP)  is  not  a  bit  vector  expression  and  AT  is  not  a  logical  expression. 

The  code  generated  is  quite  efficient  but  not  optimal.  In  Figure  Bl, 
only  four  temporary  variables  were  generated  and  occupied  only  22  words  of 
storage.  A  small  amount  of  superfluous  code  is  present.  For  example,  the 
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word-index  pair  for  bit  position  V  Is  computed  twice  in  the  sequence  of 
statements  - 

TV ( V)  =  .TRUE. 

CALL  LIST(LOCAL(P) .DIFF .FORMAL(P) .INTER. OPT(P) ,NVAR) 

TV ( V)  =  .FALSE. 

when  it  only  needed  to  be  computed  once. 


FIGURE  Bl:  SAMPLE  TRANSFORMATION 


CONSTANT  NPROC  -  100 
CONSTANT  NINV  -  500 
CONSTANT  NVAR  -  1000 
CONSTANT  NSET  -  3000 


SUBROUTINE  AL IA S < LOCAL , FORMAL , 0 PT , NCALL , CALLST , INVOK , NUMP , 
*  AT, SET, NUMS) 

BIT  VECTOR(NVAR)  LOCAL ( N PROC ), FO RMAL ( N PROC ), 0 PT ( NPROC ) 

INTEGER  NCALL(NPROC) , CALLST ( N PROC ) .INVOK(NINV) 

BIT  VECTOR (NPROC)  AT ( N S ET ) , ATB ( NSET ) 

BIT  VECTOR ( NVAR)  SET(NSET) 

BIT  VECTOR ( NVAR)  TV 

BIT  VECTOR(NPROC)  TP 

COMMON  /LIST/  LLST, LARR( NVAR) 

INTEGER  V,P,R,E 


CALL  INTHSH 

WKP-0 

TP* . EMPTY, 

TV- . EMPTY. 

DO  30  P-1, NUMP 
TP(P)» . TRUE. 

CALL  LIST ( LOCAL ( P ) . D IF F . FORMAL ( P ) . INTER . OPT ( P ) .NVAR) 
IF  (LLST. EQ. 0)  GO  TO  30 
DO  20  I- 1 .LLST 
V-LARR ( I ) 

TV(V)-. TRUE. 

SN-HASH(TV, SET, NUMS) 

TV(V)-. FALSE. 

AT( SN)-TP 
WKP-WKP+1 

20  WL IST( WKP) - SN 
30  TP(P)-. FALSE. 


y  ■*' 
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40  IF  (WKP.EQ.O)  RETURN 
SN=WL 1ST ( WKP ) 

WKP-WKP-1 

CALL  LIST (AT ( S N )  . D IFF . ATB< SN)  ,NPROC) 
ATB ( SN ) “AT ( SN) 

DO  60  I-l.LLST 
P-LARR(I) 

L-NCALL(P) 

K-CALLST(P) 

L-K+L-l 
DO  60  E  =  K , L 
R-INVOK(E) 

CALL  FOPT(XP, SN, E) 

SNP-HASH(XP , SET.NUMS) 

IF  ( .NOT. ATB(SNP) (R) )  GO  TO  60 

IF  (AT(SNP) .NE. ATB(SNP) )  GOTO  50 
WKP-WKP+1 
WLIST(WKP)-SNP 
50  AT(SNP) (R)« . TRUE. 

60  CONTINUE 

GO  TO  40 


END 


u  o  o 
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BLOCKD  DATA  AQOOQl 
COMMON  /A00000/  100000(60) 

DATA  100000(1 ) /4000000 OOP 000000 00 OOB/  . 100000(2) 72000000000000000 
*ooooB/ «iooooo(3) /looooooooonoooonooooB/ 


DATA  100000  (  5  8  /nOOOQOOOOOOOOOOOOOQ4B /  . 100000(59)  /00000000000000 
*000000B/ .10  0000(60)  /OOOOOOOOOQOOOOOOOOOIB/ 

END 


•  • 

SUBROUTINE  AL IA S < LOCAL , FORMAL , OPT , NCAL L , CALLST , INVOK , NUMP , 
*  AT, SET , NUMS) 

C 

INTEGER  LOCAL! I  7. 100) . FORMAL (17. 100) .OPT( 1 7. 100) 

C 

INTEGER  NCALL(!_Q£)  ,  CALLST<  1£Q)  .INV0K(500) 

C 

INTEGER  AT ( 2 . 3000 ) .ATB(2.3QOO) 

C 

INTEGER  SET(1 7.3000) 

C 

INTEGER  TV ( 1 7) 

C 

INTEGER  TP ( 2 ) 

C 

COMMON  /LIST/  LLST. LARR( I  OOP) 

C 

INTEGER  V , P , R , E 


COMMON  / AOOOOQ/  100000(60) 

INTEGER  100003(17) 

INTEGER  100004(2) 

LOGICAL  IQ0Q05 
LOGICAL  IfljQMS. 

C 

CALL  INTHSH 
WKP-0 

DO  10000  100000-1.2 

10.0.001  TP( 100000 )-OOOQOOOOOOOOOOOQOOOOB 
DO  10001  100000-1.17 
10001  TVLLQQOQQ)-QQQQQQOQOOOOQOOOOQQOB 
DO  10002  P-1 , NUMP 

100001 -P-( 100000-1 ) *60 

TP(100000)-IP_(IQOOQQ)  .OR, 1 0  0002(100001) 

DO  10003  100000-1.17 

1000  3  100003(10  0000) -LOCAL (100000. P)  .AND.  . NOT , FORMAL ( IOOQOO . P) ■ AND. 

* 


OPT(IOQOOO.P) 


'I 
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call  LIST ( 100003 . 1000) 

IF  (LLST.EQ.O)  GO  TO  30 
DO  20  l-l.LLST 
V-LARR(I) 

IOQOOO-(V-l) /60+1 
I00001-V-(  100000-1  ) *60 

TV ( IOOQOO ) -TV ( 10 00 00). OR. 1000 02(100001) 

SN-HASH(TV, SET, NUMS) 

I00000-(V-1 ) / 6  0+ 1 

iooooi -v-( io oooo- n *60 

TV (IOOQOO) -TV ( IOOQOO) .AND. .NOT. 100002(100001) 

DO  10004  100000-1.2 

10004  AT( IOOQOO. SN) -TP (10 0000) 

WKP-WKP+ 1 

20  WLIST(WKP) =SN 

30  I00000-(P-1 )  /60+1 

I0Q001-P-( IOOQOO- 1) *6  0 

10002  TP( IOOQOO) -TP (IOOQOO) .AND. .NOT. 100002(100001) 

C 

40  IF  (WKP.EQ.O)  RETURN 
SN-WL 1ST ( WKP ) 

WKP-WKP-1 

DO  10005  100000-1.2 

10005  100004(100000) -A T(IOOOOO.SN) -AND. . NOT. ATB( IOOOQO. SN) 

CALL  LIST(I00Q04. 100) 

DO  10006  100000-1.2 

10006  ATB ( IOOOOQ. SN)- AT ( IOOQOO. SN) 

DO  60  I-l.LLST 

P-LARR(I) 

L-NCALL(P) 

K-CALLST ( P ) 

L-K+L-l 
DO  60  E-K.L 
R-INVOK(E) 

CALL  FOPT(XP, SN, E) 

SNP»HASH(XP, SET, NUMS) 

IOOQOO- ( R- 1 ) 760+1 
IOOOOl-R-(IOOOOO-l)*6Q 

100005- (ATB( IOOQOO. SNP) , AND. 100002 ( IOOOOI )). NE . 0 
IF  ( .NOT. 100005)  GO  TO  60 
I00006-. FALSE. 

DO  10007  100000-1.2 

10007  10 0006- 10 OOP  6. OR .AT (10 QOOO. SNP)  . N E ■ ATB ( 10 QOQQ . SNP ) 
IF  (10000.6)  GOTO  50 

WKP-WKP+1 
WL 1ST (WKP) -SNP 

50  IOOOQO-(R-l) /6Q+1 

IOOOOl-R-(IOOOQO-l) *60 

AT(IOOQOQ.SNP)-AT(IQOQQO. SNP) .OR.  I0QQQ2(  IflflQQL) 

60  CONTINUE 

GO  TO  40 


END 


n  o  o  non 
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FIGURE  B2:  BIT  VECTOR  TRANSLATION  SPECIFICATION 


GLOBAL  CONS 
STRING 
INTEGER 

* 

LOGICAL 

END 


BIT, ZERO.UNIV, WRDS, INDEX, IN DX 2, ERRS, GLON 
WRDLEN , IKUND.1KSMP, I KARR, IKABV, IKS  EL, 
IKLHS , IKVAL,IKONE, IKZER, IKCON 

DECLAR 


START  OF  TEXT 
INCLUDE  CONS 


WRDLEN  -  60 
WRDS  -  $60$ 

UNIV  -  $77777777777777777777B$ 
ZERO  -  $OOOOOOOOOOOOOOOOOOOOB$ 
ERRS  -  $**ERROR**$ 

IKUND  -  1 
IKSMP  -  2 
IKCON  -  2 
I KARR  -  3 
IKABV  -  4 
IKSEL  -  5 
IKLHS  -  6 
IKVAL  -  7 
IKONE  -  8 
IKZER  -  9 


BIT  -  . GENI . 

GLON  -  .GENG. 

EXECUTE  $BLOCK  DATA  $* . GENG , 

EXECUTE  $COMMON  /$*GLON*$/  $ *BI T* $ ( $* WRDS* $ ) $ 
DO  20  1-1,20 
S  -  . EMPSTR. 

DO  10  J-1,3 

ZERO (I)  -  . CONVER. ( 2**(3-J) ) 


10 

20 


ZERO(I) 

EXECUTE 

EXECUTE 

RETURN 

END 


S* BIT* $<$* .CONVER.  ( 3*I+J-3)*$) /$*ZERO*$/ ,$ 
-  $0$ 

$DATA  $*S(0, .LENGTH. S) 

$END$ 


O  U  U  U  U  U  U  O  u  o  o  o  o  o  t?  t>  o 


-43- 


STATEMENT/N/  $CONSTANT$-. ID. /A-$»$-. INT. /B 


INCLUDE  CONS 
HEAP  HA 


LOOKUP (GLOBAL)  A  IN  HA 
IF  ( .UNDEF.HA)  GO  TO  10 
EXECUTE  $CONSTANT  $*ERRS 
RETURN 
NEW  HA( 2 ) 

HA(1,.INT.)  -  IKCON 
HA( 2 , . STR . )  -  B 
RETURN 
END 


START  OF  UNIT (A) 


INCLUDE  CONS 


DECLAR 

RETURN 

END 


.TRUE. 


ENTRY 

INCLUDE  CONS 
STRING  S 


INDEX  -  . GENI . 
INDX2  -  .GENI. 
BIT  -  .GENI. 
DECLAR  -  .FALSE. 


DECLARE  SCOMMON  /$*GLON*$/  $*BIT* $ ( $* WRDS*$ ) $ 

RETURN 

END 


O  O  O  U  O  O  UUOU  u  o 


-44- 


STATEMENT/ S/  $B IT$-$ VECTORS -$($-. INT. /A-$) $-LIST( .REF.  ) /B 

INCLUDE  CONS 
STRING  LENS 


NBIT  -  . 1NTERP . A 

LEN  -  (NBIT-1 ) /WRDLEN+1 

LENS  -  . CONVER . LEN 

CALL  DECBIT(B, LEN, LENS) 

RETURN 

END 


STATEMENT/ S/  $BIT$-$VECTOR$-$ ($-.ID./A-$)$-LIST(. REF. ) /B 

INCLUDE  CONS 
STRING  LENS 
HEAP  HA 


LOOKUP (GLOBAL)  A  IN  HA 
IF  (.UNDEF.HA)  GO  TO  10 

NBIT-  . INTERP. HA(2 , . STR. ) 
LEN  -  (NBIT-1) /WRDLEN+1 
LENS  -  .CONVER. LEN 
GO  TO  20 
10  LEN  -  1 

LENS  -  ERRS 

20  CALL  DECBIT(B, LEN, LENS) 
RETURN 
END 


o  u  o  o  u  o  u 
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SUBROUTINE  DEC BIT ( B , L EN , L ENS ) 

INCLUDE  CONS 
STRING  LENS  ,  S 

HEAP  B,HB 

INTEGER  REFERENCE  TRAN 


J  -  .LENGTH. B 

S  -  .EMPSTR. 

DO  40  I-l.J 

CATCH  B ( I , .STR.)  IN  HB 
IB-TRAN(HB) 

GO  TO  (10,30,30,20,30,30,30,30,30) , IB 
10  S  *  S*B(I, .STR. )*$($*LENS*$)  ,  $ 

NEW  HB ( 2 ) 

HB ( 1 , . INT . )  -  IKSMP 
HB ( 2 , . INT. )  -  LEN 
GO  TO  40 

20  S  S*HB(2, .STR. ) *LENS*$ , $*HB (3 , .STR. )*$,$ 

HB ( 1 , . INT . )  -  I KARR 
HB( 2 , . INT. )  -  LEN 
GO  TO  40 

30  S  -  S* ERRS* $ , $ 

40  CONTINUE 

DECLARE  $  INTEGER  $* S ( 0 ,. LENGTH . S) 

RETURN 

END 
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identifier  A«*B* 

INCLUDE  CONS 
HEAP  H , HB 

INTEGER  REFERENCE  TRAN 


IF  (DECLAR)  GO  TO  100 

LOOKUP (GLOBAL)  B  IN  HB 

IF  (  .NOT.  .UNDEF.HB)  GO  TO  40 

LOOKUP  B  IN  HB 

IB-TRAN(HB) 

GO  TO  (30,10,20,30,30,30,30,30,30)  , IB 
10  A  -  B*$( $*INDEX*$) $ 

NEW  H( 3) 

H(1,.INT.)  -  IKLHS 
GO  TO  25 


20 

A  -  B* $ ( $* IN DEX* $ , $ 

NEW  H( 3 ) 

H( 1 , . INT. ) 

-  IKABV 

25 

H( 2 , .INT. ) 

-  HB ( 2 , .INT. ) 

H( 3 , . STR. ) 

-  B 

30 

PASS  H 

A  -  B 

40 

RETURN 

A  -  HB ( 2  ,  . 

STR.  ) 

NEW  H (  1  ) 

H( 1 , . INT. ) 

-  1KCON 

100 

PASS  H 

A  -  B 

LOOKUP (GLOBAL )  B  IN  HB 
IF  (.UNDEF.HB)  LOOKUP  B  IN  HB 
PASS  HB 


END 


U  U  O  U  CJ  u  u 
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REFERENCE  A«*B*(*C*) 

INCLUDE  CONS 
STRING  T  L ,  S 

HEAP  H,HB,HC 

INTEGER  REFERENCE  TRAN 
STRING  REFERENCE  EVAL 


CATCH  B  IN  HB 
IB  -  TRAN(HB) 

J  -  .LENGTH. C 
IF  (DECLAR)  GO  TO  200 

IF  (IB.GT.IKABV.AND. J.NE. 1)  GO  TO  10 
GO  TO  (70,10,  10,60, 10,40,50,20,30)  , IB 
10  A  »  ERRS 
RETURN 

20  A  -  $ . TRUE . $ 

RETURN 

30  A  -  $. FALSE. $ 

RETURN 
40  A  -  B 

HB( 1 , . INT . )  -  IKSEL 

HB ( 2 , . STR. )  -  B 

HB( 3 , .STR.)  -  C ( 1 , .STR.) 

PASS  HB 

50  A  -  EVAL(B,C( 1 , . STR. ) ) 

RETURN 

60  A  -  . EMPSTR. 

DO  65  I-1,J 

65  A  -  A*C ( I ,  . STR . ) *  $ , $ 

A  -  A(0 , .LENGTH. A)*$)$ 

HB( 1 , . INT . )  -  IKLHS 

HB ( 3 , . STR . )  -  HB(3, .STR. )*$($*A 

A  -  B*A 

PASS  HB 
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70  A  *  B* $ ( $ 

DO  130  I-l.J 

CATCH  C(I, .STR. )  IN  HC 
IC  -  TRAN (HC) 

GO  TO  (120, 120, 1  10, 80, 90,80,  100, 110, 1  10), IC 
80  A  -  A*HC<3, .STR. )*$,$ 

GO  TO  130 

90  A  -  A*EVAL(HTPC(2,.STR.) ,HC(3, .STR. ))*$,$ 

GO  TO  130 

100  TL  =  .GENI. 

DECLARE  $  I NTEGER  $*TL*$ ( $* . CONVER. HC( 2 , . INT.  )  *$  )  $ 
CALL  LOOP(TL*$( $* INDEX* $ ) - $*C ( I , . STR. ) , HC(2 , . INT. ) ) 
A  -  A*TL*  $ , $ 

GO  TO  130 

110  A  -  A* ERRS* $ , $ 

GO  TO  130 

120  A  -  A* C ( I , .STR. )*$,$ 

130  CONTINUE 

A  -  A ( 0 , .LENGTH. A)*$)$ 

RETURN 

200  S  -  .EMPSTR. 

DO  210  I-1,J 

210  S  -  S*C(I, .STR. )*$,$ 

S  -  S(0, .LENGTH. S)*$)$ 

A  -  B*$ ( $*S 

IF  (IB.NE.IKUND)  PASS  HB 
NEW  HB ( 3 ) 

HB ( 1 , .1 NT . )  -  IKABV 
HB( 2 , .STR.)  -  B* $ ( $ 

HB(3 , . STR. )  -  S 
PASS  HB 

END 


o  o  o  o  o  n  n  no  o  non 
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ZOP  A-. EMPTY. 

INCLUDE  CONS 
HEAP  H 


A  *  ZERO 
NEW  H ( I ) 

H ( 1 , . 1NT . )  -  IKZER 

PASS  H 

END 


UOP  A-.NOT.B 

INCLUDE  CONS 
HEAP  HB 

INTEGER  REFERENCE  TRAN 
STRING  REFERENCE  EVAL 


CATCH  B  IN  HB 
IB  -  TRAN(HB) 

IF  (IB.NE. IKSEL)  GO  TO  10 
IB  -  IKUND 

B  -  EVAL(HB(2,  . STR . )  , HB ( 3  ,  . STK 
10  IF  (IB. EQ. IKUND)  GO  TO  20 
A  -  ERRS 
RETURN 

20  A  -  $ . NOT . $* B 
RETURN 
END 


on  o  n  non  no  n  noon  on  n  non 
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BOP  A-B .AND. ( 5 00 ) C 
STRING  REFERENCE  BOOL 


A  -  B00L(B,$. AND . $ , C ) 

RETURN 

END 


BOP  A-B. OR. (500)C 
STRING  REFERENCE  BOOL 


A  -  BOOL(B,$.OR. $ , C) 

RETURN 

END 


STRING  FUNCTION  BOOL(B,OP,C) 

INCLUDE  CONS 
HEAP  HB.HC 

STRING  B,OP,C 

INTEGER  REFERENCE  TRAN 
STRING  REFERENCE  EVAL 


CATCH  B  IN  HB 
CATCH  C  IN  HC 
IB  -  TRAN ( HB) 

IC  -  TRAN ( HC) 

IF  (IB.NE.IKSEL)  GO  TO  10 
IB  -  IKUND 

B  -  EVAL(HB( 2 ,  . STR. )  , HB ( 3  ,  . STR. ) ) 

10  IF  (IC.NE. IKSEL)  GO  TO  20 
IC  -  IKUND 

C  -  EVAL(HC(2, .STR. ) ,HC(3, .STR. ) ) 

20  IF  (IB.LE. IKCON. AND. IC.LE. IKCON)  GO  TO  30 
BOOL  -  ERRS 
RETURN 

30  BOOL  -  B*OP*C 
RETURN 
END 


no  n  n  o  non 
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BOP  A-B.NE. <A00)C 
INCLUDE  CONS 
HEAP  HB.HC 

INTEGER  REFERENCE  TRAN 
STRING  REFERENCE  BOOL 


CATCH  B  IN  HB 
CATCH  C  IN  HC 
IB  -  TRAN ( HB) 

IC  -  TRAN (HC) 

IF  (IB.LE. IKSEL.OR. IC.LE. IKSBL)  GO  TO  50 
IF  (IB. GE. IKONE)  GO  TO  10 
J  -  HB ( 2 , .INT. ) 

GO  TO  20 

10  IF  (IC. GE. IKONE)  GO  TO  30 
J  -  HC( 3 , . INT. ) 

20  A  -  . GENI . 

DECLARE  $LOGICAL  $*A 
EXECUTE  A*$-. FALSE. $ 

CALL  LOOP(A*$-$*A*$ .OR. $*B*$ . NE. $*C, J) 
RETURN 

30  IF  (IC.EQ.IB)  GO  TO  AO 
A  -  $. FALSE. $ 

RETURN 

AO  A  -  $ . TRUE . $ 

RETURN 

50  A  -  BOOL( B , $ . NE . $ , C) 

RETURN 

END 


BOP  A-B. INTER. (20 0)C 

INCLUDE  CONS 
HEAP  HB,HC 

INTEGER  REFERENCE  TRAN 


CATCH  B  IN  HB 
CATCH  C  IN  HC 
IB  -  TRAN (HB) 

IC  -  TRAN ( HC) 

IF  (IB.LE. IKSEL. OR. 1C.LE. IKS EL)  GO  TO  30 
IF  ( IB.EQ. IKON E . OR. IC.EQ. IKZER)  GO  TO  10 
IF  (IC.EQ. IKONE.OR, IB.EQ. IKZER)  GO  TO  20 
IF  ( HB( 2 , . INT. ) . NE. HC( 2 ( . I  NT . ) )  GO  TO  30 
A  -  B*$ . AND. $*C 
HB( 1 , . INT. )  -  IKLHS 
PASS  HB 
A  -  C 
PASS  HC 
A-B 
PASS  HB 
A  -  ERRS 
RETURN 


on  n  o  n  n  n 
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BOP  A*B . D IFF . ( 1 00 ) C 

INCLUDE  CONS 
HEAP  HB.HC 

INTEGER  REFERENCE  TRAN 


CATCH  B  IN  HB 
CATCH  C  IN  HC 
IB  -  TRAN ( HB) 

IC  -  TRAN ( HC) 

IF  (IB .LE. IKS  EL. OR. IC.LE. IKS  EL )  GO  TO  30 
IF  (IB.EQ.IKZER.OR.IC.IKZER)  GO  TO  20 
IF  (IC.EQ. 1KONE)  GO  TO  15 
IF  (IB.EQ. IKONE)  GO  TO  10 
IF  (HB(2, . INT. ) .NE. HC(2, . INT. ) )  GO  TO  30 
A  -  B*$ . AND . . NOT, $*C 
HB( 1 ,  . INT. )  -  IKVAL 
PASS  HB 

10  A  -  $ . NOT. $*C 

HC( 1 , . INT. )  -  IKVAL 
PASS  HC 
15  A  -  ZERO 

HC( 1 , . INT. )  -  IKZER 
PASS  HC 
20  A  -  B 

PASS  HB 
30  A  -  ERRS 
RETURN 
END 


on  o  n  n  on 


-54- 


STATEMENT/E/  . RE F . / A- $- $- . EX P . / B 

INCLUDE  CONS 
HEAP  HA, HB 

LOGICAL  LOGT , LOGF 
STRING  C1,TRG,T1,T2 

INTEGER  REFERENCE  TRAN 


CATCH  A  IN  HA 
CATCH  B  IN  HB 
IA  -  TRAN ( HA) 

IB  -  TRAN ( HB) 

GO  TO  (40, 10,  10, 10, 20, 30, 10, 10, 10), IA 
10  EXECUTE  $ASSIGN  $*ERRS 
RETURN 

20  IF  (IB.EQ. IKUND)  GO  TO  21 
IF  ( IB .NE. IKSEL)  GO  TO  10 

B  -  EVAL(HB(2, . STR. ) , HB( 3 , . STR. ) ) 

21  Cl  -  HA( 2 , .STR.) 

TRG  -  HA( 3 , .STR. ) 

EXECUTE  INDEX*$»($*C1*$-1) /$*WRDS*$+1$ 

EXECUTE  1NDX2*$-$*C1 *$-($* INDEX* $-l)*$*WRDS 
LOGT  -  B . EQ . $ . TRUE . $ 

IF  (LOGT)  GO  TO  22 
LOGF  -  B.EQ. $. FALSE. $ 

IF  (LOGF)  GO  TO  23 
T1  -  .GENL. 

T2  -  .GENL. 

EXECUTE  $  I F  ( $*B*  $)  GO  TO  $*T1 

22  EXECUTE  $  $*TRG*$-$*TRG*$ . OR. $*BIT*$( $*INDX2*$) $ 

IF  (LOGT)  RETURN 

EXECUTE  $  GO  TO  $*T2 
LABEL  T 1 

23  EXECUTE  $  $*TRG* $-$*TRG* $ . AND. . NOT. $*BIT*$ ( $*INDX2* $ ) $ 
IF  (LOGF)  RETURN 

LABEL  T2 
RETURN 

30  GO  TO  (10, 10, 10, 10, 10, 31, 31, 32, 32), IB 

31  IF  (HB(2, . INT . ) . N E . HA( 2 , . INT . ))  GO  TO  10 

32  CALL  LOOP(A*$-$*B,HA(2, .INT. ) 

RETURN 

40  GO  TO  (50,50,10,10,45,10,10,10,10)  , IB 
45  EXECUTE  A*$-$*EVAL( HB ( 2 , . STR. ) , HB ( 3 , . STR. ) ) 

RETURN 

50  EXECUTE  A*$-$*B 

RETURN 


END 


n  n  n  non  n  n  n  n  o  o  o  o  o  n  n  n  n 


SUBROUTINE  LOOP( STR, LEN) 

INCLUDE  CONS 
STRING  STR, LAB 


LAB  -  .GENL. 

EXECUTE  $DO  $*LAB*$  $* INDEX* $-1 ,$*. CONVER. LEN 

LABEL  LAB 

EXECUTE  $  $*STR 

RETURN 

END 


STRING  FUNCTION  EVAL ( STRB , STRC ) 

INCLUDE  CONS 
STRING  STRB, STRC 


EVAL  -  , GENI . 

DECLARE  $LOG ICAL  $*EVAL 

EXECUTE  INDEX*$-($*STRC*$-I) /$*WRDS*$+1$ 

EXECUTE  INDX2*$-$*STRC*$-($*INDEX*$-1)*$*WRDS 

EXECUTE  EVAL* $-($* STRB* $. AND. $* BIT* $($*INDX2*$) ) .NE.0$ 

RETURN 

END 


INTEGER  FUNCTION  TRAN (HP) 

INCLUDE  CONS 
HEAP  HP 


TRAN  -  IKUND 
IF  (.UNDEF.HP)  RETURN 
TRAN  -  HP ( 1 , .INT.) 
RETURN 
END 


$ 


